1. Field of the Invention
This invention relates to Public Key Infrastructures (PKI), and more specifically to recovery of encryption certificates in a PKI.
2. Background Information
A public key infrastructure (PKI) is a collection of servers and software that enables an organization, company, or enterprise to distribute and manage thousands of unique public/private cryptographic keys in a manner that allows users to reliably determine the identity of the owner of each public/private key pair. When each member of an enterprise has a unique key, paper-based business processes may be transitioned to an online, electronic equivalent. Public/private key pairs have the property that for any given public key there exists one and only one private key, and vice versa. Public key cryptography (i.e., the ability to publicly distribute the encryption key) can be used to digitally sign documents. If a particular message can be decrypted using one member of the key pair, then the assumption is that the message must have been encrypted using the other member. If only one person knows the key used to perform the encryption of a document in the first place, then the recipients that can decrypt the document can be sure that the sender of the document must be that person.
However, for a digital signature to be meaningful, the recipient of an object signed with the digital signature must first be able to reliably determine the owner and integrity of the key used to sign the object. Public infrastructures accomplish this using an electronic document called a digital certificate. Certificates may contain information identifying the owner of the key pair, the public component of the pair, and the period of time for which the certificate is valid. The certificate may also identify technical information about the key itself, such as the algorithm used to generate the key, and the key length. Certificates are generated by organizations, companies, or enterprises that are responsible for verifying the identity of individuals (or in some instances organizations) to which certificates are issued. The certifying organization is known as a certificate authority. The certificate authority signs each certificate using a private key known only to the certificate authority itself. This allows users of the PKI to verify both the integrity of the certificate and the identity of the authority that issued it. By issuing a certificate, a certificate authority is stating that it has verified that the public key that appears in the certificate (and, by extension, the corresponding private key) belongs to the individual listed in the certificate. The integrity with which the registration process operates is, therefore, of great importance. The process must provide mechanisms for reliably identifying the individual and for verifying that the public key listed in the certificate belongs to that individual.
FIG. 1 shows a block diagram of an example PKI system architecture. Current PKIs that provide strong authentication of user identity accomplish this via the use of a local registration authority officer (LRAO) 12. LRAO 12 operates at a work station or server platform 14 that runs a local registration authority software application 16. Server platform 14 may be any known computing device that may serve as a server, e.g., computer, workstation, etc. The local registration authority application 16 interfaces to other server platforms that may contain applications such as a certificate authority application 18, a registration authority application 20, and/or a key recovery authority application 22. Each application may be on the same server platform, or on separate individual server platforms 14. A user 10, that is using or desires access to the PKI system architecture, accesses the system via a web browser 22 on a client platform 24. A hardware token 26, such as a smart card, may also be operably connectable to client platform 24. Typically in current systems, user 10 presents a photo I.D. to the local registration authority officer 12 in order to authenticate the user's identity. Local registration authority officer 12 then uses workstation 14 and local registration authority application 16 to signal a registration authority application 20 to register new user 10 in the system. Local registration authority application 16 may be off-the-shelf product software that comes typically bundled with a certificate authority application 18, registration authority application 20, and key recovery authority 22 software.
A public/private key pair is generated by either the local registration authority application 16 or the registration authority application 20 (depending on products chosen and depending on how they've been configured). The public key is sent to certificate authority application 18 to be signed, thereby, generating a certificate for new user 10. A backup copy of the private key may also be sent to key recovery authority application 22, however, normally the private key is kept on a token 26, or at client platform 24 by user 10. Once the public key is sent to a certificate authority 18 and signed, a user certificate is generated and provided to a local registration authority server. Local registration authority officer 12 copies the certificate (including the private key) onto a floppy disk, hardware token, or other storage medium, and then provides the certificate and private key to the user.
A person in the enterprise may wish to access a document that has been encrypted via a user's encryption certificate (either the user's current certificate or one of the user's previous certificates). The user might be unable to, or unwilling to, decrypt the document personally. Or, the user may have left the enterprise, therefore, being unavailable to decrypt the document. The document that has been encrypted with the user's encryption certificate may be a current document, or may be an historical document that was written or archived by that user. In any event, a third party who wishes to decrypt one or more documents of a user, must recover the encrypted certificate used by the user in order to decrypt the document(s).
Current PKI systems make no distinction between current users and former users of an enterprise in terms of certificate recovery. Depending on the PKI being used, the person desiring recovery of the user certificate, e.g., an enterprise officer, presents a photo I.D. to either a local registration authority officer (LRAO) or a key recovery officer (KRO) of the enterprise in order to authenticate the identity of the enterprise officer. Either the local registration authority officer or the key recovery officer uses server software to signal a key recovery authority to recover a copy of the old encryption certificate belonging to the user. The user's encryption certificate is then provided to the local registration authority or the key recovery officer (depending on the PKI being used). The local registration authority officer (or the key recovery officer) copies the certificate on to a floppy disk, hardware token, or other storage medium and hands the certificate to the requesting enterprise officer. Therefore, recovery of a user's encryption certificate may be obtained by contacting one enterprise officer, either the local registration authority officer or a key recovery officer.
However, in order to protect the confidentiality of encrypted documents, an enterprise may not want to make the recovery of encryption certificates too easy. For example, an enterprise may choose to enforce a policy that a certificate may be recovered only upon the agreement of two trusted officers. The two trusted officers are chosen such that it is unlikely that the two officers will enter into collusion to defraud or otherwise harm the enterprise or the user. However, maintaining a cadre of such officers may be expensive in terms of labor costs.
Moreover, current recovery of encryption certificates using local recovery approval are problematic in that they: are time consuming due to having to contact a local recovery approval (e.g., LRAO or KRO); untimely because key recovery is subject to the work load and availability of the local recovery approval; costly because of the need for multiple local recovery approvals in a large enterprise; inefficient in locating and providing a user's encryption certificate to a requester; and less secure because local recovery approvals have minimum checks and balances to avoid unauthorized recovery of user encryption certificates.
Therefore, a need exists for third party recovery of encryption certificates of a user, whereby the cost of certificate recovery is reduced without compromising the confidentiality of encrypted documents.